Block outbound calls from ci runners to unallowed endpoints#1175
Block outbound calls from ci runners to unallowed endpoints#1175
Conversation
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (10)
WalkthroughThe PR updates GitHub Actions workflows to change Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 2 minutes and 44 seconds.Comment |
spoorcc
force-pushed
the
feature/harden-runners
branch
2 times, most recently
from
4f82a71 to
5ee4598
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 10
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/build.yml:
- Around line 25-30: The egress allowlist for the step-security/harden-runner
action currently is empty while egress-policy: block is set, which will break
outbound installs; update the allowed-endpoints entries (the two
allowed-endpoints blocks associated with the harden-runner invocation) to
include the external package and metadata hosts your jobs need (for example
pypi.org and files.pythonhosted.org for pip, rubygems.org for gem,
community.chocolatey.org or chocolatey.org for choco, api.nuget.org and
nuget.org for dotnet/nuget, plus github.com and raw.githubusercontent.com if
workflows fetch releases), ensuring both occurrences (the block at the top and
the one around lines ~211-216) are populated before enforcing egress-policy:
block.
In @.github/workflows/codeql-analysis.yml:
- Around line 37-42: The workflow sets step-security/harden-runner with
egress-policy: block but leaves allowed-endpoints empty (allowed-endpoints: >+),
which will block outbound calls needed by actions/checkout; fix by populating
allowed-endpoints with the required hosts (at minimum github.com:443 and
api.github.com:443, and optionally raw.githubusercontent.com:443) or change to a
Policy Store-backed configuration instead of block mode so actions/checkout can
access the network; update the allowed-endpoints entry in the harden-runner step
accordingly.
In @.github/workflows/dependency-review.yml:
- Around line 19-23: The workflow currently sets step-security/harden-runner
with egress-policy: block while leaving allowed-endpoints blank, which will
block all outbound traffic and break steps like actions/checkout and
actions/dependency-review-action; fix by populating allowed-endpoints with the
necessary GitHub endpoints (e.g., api.github.com, github.com,
raw.githubusercontent.com, uploads.github.com, objects.githubusercontent.com and
any required registry or API hosts your jobs need) so that the harden-runner
action (egress-policy and allowed-endpoints) allows those outbound calls; ensure
allowed-endpoints is not empty and includes any additional third-party hosts
used by your jobs.
In @.github/workflows/devcontainer.yml:
- Around line 18-22: The harden-runner step currently sets egress-policy: block
with an empty allowed-endpoints list, which blocks all outbound traffic; update
the step-security/harden-runner action configuration (the harden-runner step
using egress-policy and allowed-endpoints) to include the required endpoints
(e.g., api.github.com, github.com, raw.githubusercontent.com, npm
registry/registry.npmjs.org or your container registry, and any build/dependency
hosts) or else change egress-policy to allow or remove the harden-runner step
until you provision a Policy Store policy; ensure allowed-endpoints contains all
hosts needed by checkout, Docker/push/pull, and package managers so subsequent
steps can access the network.
In @.github/workflows/docs.yml:
- Around line 19-23: The workflows set harden-runner with egress-policy: block
and an empty allowed-endpoints, which blocks all outbound traffic (breaking
actions/checkout and pip installs); update each job that uses harden-runner with
egress-policy: block (look for uses: step-security/harden-runner and the
allowed-endpoints field) to include at minimum the allowlist entries
github.com:443, api.github.com:443, pypi.org:443, and files.pythonhosted.org:443
under allowed-endpoints so checkout, PyPI installs and actions-gh-pages can
reach their endpoints, or alternatively switch those jobs to use StepSecurity’s
Policy Store if you want a centralized allowlist.
In @.github/workflows/python-publish.yml:
- Around line 23-27: The workflow currently sets step-security/harden-runner
with egress-policy: block but leaves allowed-endpoints empty, which will block
all outbound network calls and break subsequent steps; update the harden-runner
configuration by populating allowed-endpoints with the required host:port
entries (e.g., github.com:443, api.github.com:443, pypi.org:443 and any other
services your job needs) or switch to using the Policy Store option instead so
that actions/checkout, actions/setup-python, pip installs and artifact uploads
can reach their endpoints; modify the block in the
.github/workflows/python-publish.yml where allowed-endpoints is declared to
include the necessary endpoints.
In @.github/workflows/release.yml:
- Around line 24-27: The prepare-release job is using harden-runner with
egress-policy: block and an empty allowed-endpoints list so actions/checkout
cannot reach GitHub; update the job configuration (prepare-release) to either
switch egress-policy to audit or populate allowed-endpoints with the GitHub
domains required by actions/checkout (at minimum github.com,
raw.githubusercontent.com and api.github.com) so outbound access to those
endpoints is permitted, or start in audit mode to discover additional domains
before locking down.
In @.github/workflows/run.yml:
- Around line 18-23: The workflow sets step-security/harden-runner with
egress-policy: block but leaves allowed-endpoints empty (allowed-endpoints: >+),
which blocks all outbound traffic and causes checkout to fail; update the
hardened runner usage by populating allowed-endpoints with the necessary
endpoints (GitHub API/registry domains, actions/checkout host, package
registries, etc.) or switch to audit mode while iterating; locate the step
referencing step-security/harden-runner and the keys egress-policy and
allowed-endpoints and add the required hostnames/URLs for both occurrences (the
block at lines shown and the similar block at lines 77-81) so actions/checkout
and other network calls are permitted.
In @.github/workflows/scorecard.yml:
- Around line 29-33: The workflow currently sets the harden-runner step (uses:
step-security/harden-runner) with egress-policy: block but leaves
allowed-endpoints empty, which blocks outbound calls required by
actions/checkout; update the allowed-endpoints value for that harden-runner
invocation to include at minimum github.com:443 and api.github.com:443 (or apply
the recommended allowed endpoints policy from the step-security/harden-runner
docs) so actions/checkout and GitHub API calls are permitted.
In @.github/workflows/test.yml:
- Around line 13-17: The workflow currently sets step-security/harden-runner
with egress-policy: block but leaves allowed-endpoints empty, which blocks all
outbound traffic and breaks steps like actions/checkout, apt-get, pip install
and codacy upload; fix by populating allowed-endpoints with the required
hostnames/IPs (e.g., github.com, api.github.com, debian/apt repos, pypi.org,
files.pythonhosted.org, Codacy endpoints) or change egress-policy to allow or
configure a Policy Store before merging so the harden-runner step does not block
necessary network calls; update the allowed-endpoints entry in the harden-runner
step accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: fda5d88b-5845-468d-ba06-3dd79af4543c
📒 Files selected for processing (10)
.github/workflows/build.yml.github/workflows/codeql-analysis.yml.github/workflows/dependency-review.yml.github/workflows/devcontainer.yml.github/workflows/docs.yml.github/workflows/python-publish.yml.github/workflows/release.yml.github/workflows/run.yml.github/workflows/scorecard.yml.github/workflows/test.yml
| - name: "Harden the runner (Block egress traffic: Only allow calls to allowed endpoints)" | ||
| uses: step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40 # v2.19.0 | ||
| with: | ||
| egress-policy: audit | ||
| egress-policy: block | ||
| allowed-endpoints: >+ |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat .github/workflows/scorecard.yml | head -60Repository: dfetch-org/dfetch
Length of output: 2150
🏁 Script executed:
# Check if there's more context in the workflow or if endpoints are defined elsewhere
rg -A 10 "allowed-endpoints" .github/workflows/scorecard.ymlRepository: dfetch-org/dfetch
Length of output: 424
🌐 Web query:
step-security harden-runner block mode empty allowed-endpoints behavior
💡 Result:
In StepSecurity's Harden-Runner GitHub Action, when using block mode (egress-policy: block) with an empty allowed-endpoints list (default is ""), Harden-Runner blocks all outbound network connections except those automatically allowed for its own operation (e.g., to StepSecurity APIs over TLS, which do not need explicit addition). Any other outbound traffic to endpoints not explicitly listed is blocked at DNS (Layer 7) and network layers (Layers 3/4), including DNS exfiltration attempts. This creates a restrictive deny-by-default policy, preventing data exfiltration. Workflows typically fail if they require external network access without allowed endpoints configured, as seen in guides for fixing blocked endpoints by adding legitimate ones after audit mode. Examples always include specific endpoints like github.com:443 when using block mode. Policy Store can centralize allowlists, but local empty list takes precedence and enforces strict blocking.
Citations:
- 1: https://docs.stepsecurity.io/guides/how-to-restrict-network-connections-to-explicitly-allowed-endpoints
- 2: https://docs.stepsecurity.io/harden-runner
- 3: https://docs.stepsecurity.io/harden-runner/workflow-runs
- 4: https://github.com/step-security/harden-runner/blob/main/action.yml
- 5: https://docs.stepsecurity.io/guides/how-to-fix-a-blocked-endpoint-in-your-workflow
- 6: https://devansh.bearblog.dev/harden-runner-bypass/
- 7: https://docs.stepsecurity.io/harden-runner/policy-store
🌐 Web query:
actions/checkout network calls github.com egress
💡 Result:
The actions/checkout GitHub Action makes outbound network calls to github.com domains during execution, specifically to api.github.com and related endpoints. Primary network egress: - Git protocol fetches/clones/pushes to github.com (ports 22/443), using GITHUB_TOKEN or SSH key for authentication. This is the default behavior when Git is available (version 2.18+). - HTTPS git operations to github.com. Additional calls when Git is unavailable or fallback triggered: - REST API calls to api.github.com to get default branch (octokit.rest.repos.get) and download archive (downloadTarballArchive or downloadZipballArchive). - These use @actions/github library with auth token. Observed endpoints from runtime analysis (StepSecurity data on public workflows): - github.com, api.github.com, github-cloud.githubusercontent.com, objects-origin.githubusercontent.com, patch-diff.githubusercontent.com (GitHub-owned). - Incidental calls to other domains (e.g., googlesource.com mirrors for Git deps, package registries) appear in aggregate data but are not core to checkout logic; likely from Git internals, LFS, submodules, or runner environment. No calls to arbitrary external sites; all core traffic is to GitHub services. Egress is necessary for repository fetch. For self-hosted runners with strict policies, allow api.github.com:443, github.com:22/443, and githubusercontent.com domains. Sources confirm via source code inspection and monitoring tools.
Citations:
- 1: https://github.com/actions/checkout
- 2: https://www.stepsecurity.io/blog/unified-network-egress-view-centralize-github-actions-network-destinations-for-your-enterprise
- 3: https://github.com/actions/checkout/blob/main/src/github-api-helper.ts
- 4: https://github.com/actions/checkout/blob/main/src/git-source-provider.ts
- 5: https://app.stepsecurity.io/action-advisor/actions/checkout
🏁 Script executed:
# Check if there are any other harden-runner configurations in the repo that show examples
rg "harden-runner" .github/workflows/ -A 5 -B 2Repository: dfetch-org/dfetch
Length of output: 8301
Add allowed GitHub endpoints to unblock the workflow.
The allowed-endpoints list is empty, and with egress-policy: block, harden-runner will block all outbound traffic. The actions/checkout step immediately following requires access to github.com and api.github.com. Populate allowed-endpoints with at least:
github.com:443
api.github.com:443
Or use the recommended policy approach from the step-security/harden-runner documentation.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/scorecard.yml around lines 29 - 33, The workflow currently
sets the harden-runner step (uses: step-security/harden-runner) with
egress-policy: block but leaves allowed-endpoints empty, which blocks outbound
calls required by actions/checkout; update the allowed-endpoints value for that
harden-runner invocation to include at minimum github.com:443 and
api.github.com:443 (or apply the recommended allowed endpoints policy from the
step-security/harden-runner docs) so actions/checkout and GitHub API calls are
permitted.
6f64f66 to
09a27e0
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (6)
.github/workflows/devcontainer.yml (1)
18-25:⚠️ Potential issue | 🟠 Major | ⚡ Quick winExpand the allowlist for the package installs this job performs.
The current list covers GitHub and Docker registry traffic, but the later
pip install -e .[development,docs,casts]andpre-commitsteps will still need PyPI access. Add at leastpypi.org:443andfiles.pythonhosted.org:443before switching to block.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/devcontainer.yml around lines 18 - 25, The allowlist for the harden-runner step (uses: step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40) is missing PyPI hosts needed for package installs; update the allowed-endpoints value in that step to include pypi.org:443 and files.pythonhosted.org:443 (in addition to github.com:443, registry-1.docker.io:443, auth.docker.io:443) so pip install -e .[...] and pre-commit can access PyPI before egress-policy: block is applied..github/workflows/release.yml (1)
24-27:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winPopulate the release job allowlist.
This harden-runner step is still deny-all, so
actions/checkoutandactions/setup-pythonwill be blocked before release creation starts. Add the GitHub endpoints required by this job, or keep audit mode until the list is complete.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 24 - 27, The harden-runner step (step-security/harden-runner) is currently blocking all egress because allowed-endpoints is empty, which prevents actions/checkout and actions/setup-python from working; update the allowed-endpoints list under the harden-runner step to include the necessary GitHub endpoints (e.g., api.github.com, github.com, raw.githubusercontent.com, codeload.github.com, packages.github.com, actions.githubusercontent.com, and any runner update or package hosts your job needs) or switch the step to audit mode until you’ve enumerated all required hosts; modify the allowed-endpoints entry referenced in the release workflow so the egress-policy: block behavior permits those endpoints for the release job..github/workflows/dependency-review.yml (1)
19-23:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winPopulate the allowlist before enforcing block mode.
This step still blocks all outbound traffic, so
actions/checkoutand the dependency-review action will fail immediately. Add the GitHub endpoints this job needs before merging.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/dependency-review.yml around lines 19 - 23, The harden-runner step currently sets egress-policy: block before any allowed endpoints are listed, which will break actions/checkout and dependency-review; update the step-security/harden-runner usage to populate allowed-endpoints with the required GitHub endpoints (e.g., api.github.com, download.github.com, github.com, uploads.github.com, packages.githubusercontent.com, token.actions.githubusercontent.com, and any registry endpoints you use) so the job can reach GitHub services while still blocking other egress; keep the parameter name allowed-endpoints and preserve the multiline >+ format used in the diff..github/workflows/python-publish.yml (1)
23-27:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winFill the allowlist before blocking egress.
This job runs
actions/checkout,actions/setup-python, andpip install, so an empty allowlist will break the build as soon asblockis enforced. Add the GitHub and PyPI endpoints this job needs.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/python-publish.yml around lines 23 - 27, The workflow enables step-security/harden-runner with egress-policy: block but leaves allowed-endpoints empty; populate the allowed-endpoints input for the harden-runner step (the step using step-security/harden-runner) to include all required GitHub and PyPI hosts so checkout/setup-python/pip can run (e.g., github.com, api.github.com, raw.githubusercontent.com, codeload.github.com, actions.githubusercontent.com, pypi.org, files.pythonhosted.org and any mirrors your CI uses)..github/workflows/scorecard.yml (1)
29-33:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winPopulate the allowlist before enabling block mode.
allowed-endpointsis still empty here, soegress-policy: blockwill stopactions/checkoutfrom reaching GitHub and the workflow will fail immediately. Add the GitHub endpoints this job needs before merging.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/scorecard.yml around lines 29 - 33, The workflow enables the step-security/harden-runner action with egress-policy: block but leaves allowed-endpoints empty, which will block actions/checkout and other GitHub API calls; update the step named "Harden the runner (Block egress traffic: Only allow calls to allowed endpoints)" (step-security/harden-runner) to populate the allowed-endpoints list with the required GitHub endpoints (e.g., api.github.com, raw.githubusercontent.com, github.com, and any other service hosts your job needs such as marketplace or third‑party APIs used by this workflow) so the runner can reach GitHub and required external services before merging..github/workflows/run.yml (1)
18-23:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winGive the Cygwin job a real allowlist.
actions/checkout,cygwin-install-action,choco install, andpip installall need network access, so an empty allowlist will block the job end-to-end. Populate the endpoints this matrix needs instead of leaving this blank.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/run.yml around lines 18 - 23, The harden-runner step currently sets allowed-endpoints to empty which blocks network access; update the step-security/harden-runner step (the "Harden the runner (Block egress traffic...)" entry) to populate allowed-endpoints with the real allowlist needed by actions/checkout, cygwin-install-action, choco and pip — e.g. add github.com, api.github.com, codeload.github.com, raw.githubusercontent.com, pypi.org, files.pythonhosted.org, community.chocolatey.org (and chocolatey.org if used), cygwin.com plus its common mirror host(s) and any specific download hosts your cygwin-install-action or choco packages require — by listing those hosts under the allowed-endpoints key so the job can reach required endpoints.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/build.yml:
- Around line 25-39: The runner hardening step using step-security/harden-runner
currently sets allowed-endpoints in the job block but is missing endpoints
needed by the Windows jobs; update the allowed-endpoints list used by the
harden-runner step (the block with uses: step-security/harden-runner and with:
allowed-endpoints) to include community.chocolatey.org:443, api.nuget.org:443,
and uploads.github.com:443 so choco install, dotnet tool install --global wix,
and softprops/action-gh-release asset uploads succeed under egress-policy:
block.
In @.github/workflows/docs.yml:
- Around line 92-102: Add uploads.github.com:443 to the allowed-endpoints list
used by the "Harden the runner (Block egress traffic: Only allow calls to
allowed endpoints)" step (uses:
step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40) for the
pdf job, because the pdf job's publisher (softprops/action-gh-release) needs to
reach uploads.github.com to upload release assets; update the allowed-endpoints
block to include the entry uploads.github.com:443 so the publish step can
complete when egress-policy is block.
---
Duplicate comments:
In @.github/workflows/dependency-review.yml:
- Around line 19-23: The harden-runner step currently sets egress-policy: block
before any allowed endpoints are listed, which will break actions/checkout and
dependency-review; update the step-security/harden-runner usage to populate
allowed-endpoints with the required GitHub endpoints (e.g., api.github.com,
download.github.com, github.com, uploads.github.com,
packages.githubusercontent.com, token.actions.githubusercontent.com, and any
registry endpoints you use) so the job can reach GitHub services while still
blocking other egress; keep the parameter name allowed-endpoints and preserve
the multiline >+ format used in the diff.
In @.github/workflows/devcontainer.yml:
- Around line 18-25: The allowlist for the harden-runner step (uses:
step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40) is missing
PyPI hosts needed for package installs; update the allowed-endpoints value in
that step to include pypi.org:443 and files.pythonhosted.org:443 (in addition to
github.com:443, registry-1.docker.io:443, auth.docker.io:443) so pip install -e
.[...] and pre-commit can access PyPI before egress-policy: block is applied.
In @.github/workflows/python-publish.yml:
- Around line 23-27: The workflow enables step-security/harden-runner with
egress-policy: block but leaves allowed-endpoints empty; populate the
allowed-endpoints input for the harden-runner step (the step using
step-security/harden-runner) to include all required GitHub and PyPI hosts so
checkout/setup-python/pip can run (e.g., github.com, api.github.com,
raw.githubusercontent.com, codeload.github.com, actions.githubusercontent.com,
pypi.org, files.pythonhosted.org and any mirrors your CI uses).
In @.github/workflows/release.yml:
- Around line 24-27: The harden-runner step (step-security/harden-runner) is
currently blocking all egress because allowed-endpoints is empty, which prevents
actions/checkout and actions/setup-python from working; update the
allowed-endpoints list under the harden-runner step to include the necessary
GitHub endpoints (e.g., api.github.com, github.com, raw.githubusercontent.com,
codeload.github.com, packages.github.com, actions.githubusercontent.com, and any
runner update or package hosts your job needs) or switch the step to audit mode
until you’ve enumerated all required hosts; modify the allowed-endpoints entry
referenced in the release workflow so the egress-policy: block behavior permits
those endpoints for the release job.
In @.github/workflows/run.yml:
- Around line 18-23: The harden-runner step currently sets allowed-endpoints to
empty which blocks network access; update the step-security/harden-runner step
(the "Harden the runner (Block egress traffic...)" entry) to populate
allowed-endpoints with the real allowlist needed by actions/checkout,
cygwin-install-action, choco and pip — e.g. add github.com, api.github.com,
codeload.github.com, raw.githubusercontent.com, pypi.org,
files.pythonhosted.org, community.chocolatey.org (and chocolatey.org if used),
cygwin.com plus its common mirror host(s) and any specific download hosts your
cygwin-install-action or choco packages require — by listing those hosts under
the allowed-endpoints key so the job can reach required endpoints.
In @.github/workflows/scorecard.yml:
- Around line 29-33: The workflow enables the step-security/harden-runner action
with egress-policy: block but leaves allowed-endpoints empty, which will block
actions/checkout and other GitHub API calls; update the step named "Harden the
runner (Block egress traffic: Only allow calls to allowed endpoints)"
(step-security/harden-runner) to populate the allowed-endpoints list with the
required GitHub endpoints (e.g., api.github.com, raw.githubusercontent.com,
github.com, and any other service hosts your job needs such as marketplace or
third‑party APIs used by this workflow) so the runner can reach GitHub and
required external services before merging.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: e6397370-acac-4e3a-8616-2a14da35cc1a
📒 Files selected for processing (10)
.github/workflows/build.yml.github/workflows/codeql-analysis.yml.github/workflows/dependency-review.yml.github/workflows/devcontainer.yml.github/workflows/docs.yml.github/workflows/python-publish.yml.github/workflows/release.yml.github/workflows/run.yml.github/workflows/scorecard.yml.github/workflows/test.yml
| - name: "Harden the runner (Block egress traffic: Only allow calls to allowed endpoints)" | ||
| uses: step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40 # v2.19.0 | ||
| with: | ||
| egress-policy: audit | ||
| egress-policy: block | ||
| allowed-endpoints: >+ | ||
| github.com:443 | ||
| api.github.com:443 | ||
| release-assets.githubusercontent.com:443 | ||
| pypi.org:443 | ||
| files.pythonhosted.org:443 | ||
| packages.microsoft.com:443 | ||
| azure.archive.ubuntu.com:80 | ||
| esm.ubuntu.com:443 | ||
| index.rubygems.org:443 | ||
| rubygems.org:443 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, let's find and read the full build.yml workflow file
find . -name "build.yml" -path "*/.github/workflows/*" | head -1Repository: dfetch-org/dfetch
Length of output: 91
🏁 Script executed:
# Read the full workflow file to understand the build job
cat -n .github/workflows/build.ymlRepository: dfetch-org/dfetch
Length of output: 11235
🏁 Script executed:
# Search for specific commands mentioned in the review
rg "choco install|dotnet tool install|softprops/action-gh-release" .github/workflows/build.yml -A 2 -B 2Repository: dfetch-org/dfetch
Length of output: 916
🌐 Web query:
Chocolatey choco install default feed endpoint community.chocolatey.org
💡 Result:
The default Chocolatey feed endpoint for community packages is: https://community.chocolatey.org/api/v2/ So your command corresponds to explicitly using the Community Repository (community feed) OData v2 endpoint.
Citations:
- 1: https://docs.chocolatey.org/en-us/choco/setup/
- 2: https://docs.chocolatey.org/en-us/choco/commands/source/
- 3: https://docs.chocolatey.org/en-us/choco/commands/sources/
🌐 Web query:
dotnet tool install NuGet feed endpoints api.nuget.org
💡 Result:
The dotnet tool install command uses NuGet feeds, with api.nuget.org (nuget.org) as the default public feed. It first fetches the V3 service index at https://api.nuget.org/v3/index.json to discover available resources and endpoints. Key endpoints used include: - Service Index: https://api.nuget.org/v3/index.json (entry point listing all resources like SearchQueryService, PackageBaseAddress, RegistrationsBaseUrl). - SearchQueryService: e.g., https://api-v2v3search-0.nuget.org/query (for package search and version resolution, specifically via NugetToolSearchApiRequest; filters for dotnet-tool packageType). - PackageBaseAddress: https://api.nuget.org/v3-flatcontainer/ (for downloading .nupkg files, e.g., https://api.nuget.org/v3-flatcontainer/{LOWER_ID}/{LOWER_VERSION}/{LOWER_ID}.{LOWER_VERSION}.nupkg). - RegistrationsBaseUrl: https://api.nuget.org/v3/registration2/ (for package metadata). If no version is specified, it queries the search endpoint on nuget.org first (fails if blocked without --version). Use --source, --add-source, or --ignore-failed-sources to control feeds. Official docs confirm dotnet tool install resolves packages via standard NuGet V3 protocol from configured sources, defaulting to nuget.org.
Citations:
- 1: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-tool-install
- 2: .NET8 RC1 dotnet tool install <package> does not work when nuget.org is blocked dotnet/sdk#35517
- 3: https://github.com/NuGet/docs.microsoft.com-nuget/blob/main/docs/api/overview.md
- 4: https://learn.microsoft.com/en-us/nuget/api/service-index
- 5: https://learn.microsoft.com/en-us/nuget/api/package-base-address-resource
- 6: dotnet tool search command should look up search URL via service index dotnet/sdk#12038
🌐 Web query:
GitHub softprops/action-gh-release upload endpoint uploads.github.com
💡 Result:
softprops/action-gh-release uploads release assets to GitHub Releases using the upload_url returned by the Releases API (a hypermedia resource). For GitHub.com, the “uploads” host you referenced (uploads.github.com) is used by the Release assets upload endpoint: POST https://uploads.github.com/repos/{owner}/{repo}/releases/{release_id}/assets This is documented as the “Upload a release asset” endpoint; GitHub expects the raw binary asset in the request body (not JSON), with appropriate Content-Type and authentication. How this maps to softprops/action-gh-release 1) The action creates (or fetches) the release. 2) It uses the release’s upload_url (returned by the Releases API) to upload each file specified via with.files. 3) The action exposes upload_url as an output (“upload_url”). So, the key point is: softprops/action-gh-release does not hardcode uploads.github.com; it uses the upload_url provided by GitHub for the specific release, whose upload host is typically uploads.github.com.
Citations:
- 1: https://docs.github.com/rest/releases/releases
- 2: https://docs.github.com/en/rest/releases/assets?apiVersion=2026-03-10
- 3: https://www.github.com/softprops/action-gh-release
- 4: https://github.com/marketplace/actions/gh-release
- 5: https://github.com/softprops/action-gh-release
- 6: https://github.com/softprops/action-gh-release/blob/master/action.yml
Add missing Windows package and release upload endpoints to the allowlist.
The Windows build jobs run choco install zig (line 53) and dotnet tool install --global wix (line 73), which require community.chocolatey.org and api.nuget.org respectively. The later softprops/action-gh-release step (line 128) uploads assets via uploads.github.com. These three endpoints are absent from the current allowlist and will cause failures under egress block mode.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/build.yml around lines 25 - 39, The runner hardening step
using step-security/harden-runner currently sets allowed-endpoints in the job
block but is missing endpoints needed by the Windows jobs; update the
allowed-endpoints list used by the harden-runner step (the block with uses:
step-security/harden-runner and with: allowed-endpoints) to include
community.chocolatey.org:443, api.nuget.org:443, and uploads.github.com:443 so
choco install, dotnet tool install --global wix, and softprops/action-gh-release
asset uploads succeed under egress-policy: block.
| - name: "Harden the runner (Block egress traffic: Only allow calls to allowed endpoints)" | ||
| uses: step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40 # v2.19.0 | ||
| with: | ||
| egress-policy: audit | ||
| egress-policy: block | ||
| allowed-endpoints: >+ | ||
| github.com:443 | ||
| pypi.org:443 | ||
| files.pythonhosted.org:443 | ||
| plantuml.com:80 | ||
| plantuml.com:443 | ||
| www.plantuml.com:80 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/docs.ymlRepository: dfetch-org/dfetch
Length of output: 5214
🌐 Web query:
GitHub release asset upload endpoint uploads.github.com softprops/action-gh-release
💡 Result:
The GitHub release asset upload endpoint is POST /repos/{owner}/{repo}/releases/{release_id}/assets, but the actual URL is dynamic and provided as the 'upload_url' in the response from the Create a release API endpoint (e.g., https://uploads.github.com/repos/OWNER/REPO/releases/RELEASE_ID/assets?X-Amz-Algorithm=... etc., with presigned parameters). It requires headers like Content-Type (e.g., application/zip), Content-Length, and authentication (e.g., Authorization: token ...). The raw binary file is sent in the request body. The softprops/action-gh-release GitHub Action handles creating/updating releases and uploading assets via the 'files' input (newline-delimited globs). It uses the GitHub Release API internally, including the upload_url for assets, and outputs the upload_url among others. It can upload to existing releases if the tag matches. Example curl from official docs: curl -L -X POST https://uploads.github.com/repos/OWNER/REPO/releases/RELEASE_ID/assets?name=example.zip -H 'Authorization: token XXX' -H 'Content-Type: application/zip' --data-binary @example.zip
Citations:
- 1: https://docs.github.com/en/rest/releases/assets?apiVersion=2026-03-10
- 2: https://docs.github.com/rest/releases/assets
- 3: https://github.com/softprops/action-gh-release
Add uploads.github.com:443 to the egress allowlist for the PDF job.
The pdf job uses softprops/action-gh-release to upload release assets, which requires access to uploads.github.com for the asset upload endpoint. Without this endpoint in the allowlist, the publish step will fail once egress is switched to block mode.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/docs.yml around lines 92 - 102, Add uploads.github.com:443
to the allowed-endpoints list used by the "Harden the runner (Block egress
traffic: Only allow calls to allowed endpoints)" step (uses:
step-security/harden-runner@8d3c67de8e2fe68ef647c8db1e6a09f647780f40) for the
pdf job, because the pdf job's publisher (softprops/action-gh-release) needs to
reach uploads.github.com to upload release assets; update the allowed-endpoints
block to include the entry uploads.github.com:443 so the publish step can
complete when egress-policy is block.
371d7a8 to
cb3e54f
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
cb3e54f to
fd31851
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
fd31851 to
0d3ed0b
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
0d3ed0b to
f06975f
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
f06975f to
700219d
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
700219d to
ce325ba
Compare
spoorcc
force-pushed
the
feature/harden-runners
branch
from
ce325ba to
a2a67bf
Compare
1 participant
Summary by CodeRabbit